Blueway Software Works (who purchased the intellectual property rights to PC/GEOS from the estate of Frank Fischer of Breadbox when he passed away) seems to have published the source code for PC/GEOS on their GitHub repository.
This repository is the official place to hold all the source code around the PC/GEOS graphical user interface and its sophisticated applications. It is the source to build SDK and release version of PC/GEOS. It is the place to collaborate on further developments.
While I can’t ascertain the exact version that they have published, it looks like it contains all of the UI options/themes provided in Ensemble 2.0 onwards (i.e. Motif, OS/2 2.0 PM and Windows 95). It also looks like they have published the source code for all of the Breadbox titles (extra games and so on) that were sold separately. By the looks of it, they are also re-factoring the source to allow it to be compiled on Windows and Linux with more modern toolchains.
Wow, it’s really written in assembly !
I used GEOS 1.2 on an IBM PS/2 Model 30 286, with 1MB of RAM and it was FAST!!!
Perhaps one can rewrite the whole think in C or C++ and make a “modern” release.
There was talk of rewriting parts of it in C/C++ about 15 years ago to do something more modern with it.
I think in the end it never got anywhere because there weren’t that many of us capable of doing it, and we each had totally different ideas about which were the important parts to keep and which parts to get rid of.
In my case, it was the GEOS-based GeoWorks Ensemble 3.0 (german version) on 386 and 486. It was often just called just “GEOS”, even though this was not the fully correct name.
For its time, the interface and the programs inside GEOS were quite innovative, compared to what “Windows” hat to offer at that time. The applications have been supporting real drag & drop – select a region in the drawing program, drag it over to the wordprocessing program, done! It also worked with diagrams generated from spreadsheets. It was an excellent environment to get real work done. And its “Solitär” game, one of the best implementations I’ve ever seen, could be used after the work was done. 😉
The “old-fashioned” Motif interface was predictable and consistent across the native applications. It was not hard for users to learn. Unlike “Windows” defaults, the mouse pointer was black with a white border and looked good (which means: it looked different than the “Windows” mouse pointer, which made the system appeal to professionals who valued everything that was superior to “Windows”, even if it was the just the typical Motif mouse pointer). GEOS also featured a setting where you could use beginner / intermediate / expert level, and the menus and icon bars would change in content accordingly. The menus themselves had a nice feature that “Windows” doesn’t seem to have even today (at least not natively): You could detach a (sub)menu with the “pin” (symbol present in every menu) and put it anywhere on the screen. You could, for example, pin a sub-sub-menu that you often needed to access. Sure, modern toolkits like those used on Linux and Unix, for example Gtk, also have had this feature for decades, but it’s probably GEOS’s Motif interface that had this feature first on the PC.
The built-in configuration tool was simple and sufficient, and you could even edit the configuration file, because it was a text file.
The built-in printer drivers worked with PS and PCL printers out of the box (I’ve been using HP Laserjet 4 and 4000). A very unique and funny thing: When GEOS printed to the Laserjet 4, the display would show the text “GEOS PCL JOB” – see “PC LOAD LETTER”. 😉
The only thing that made me sad was that I didn’t know about a way to write my own programs or tools for it. Sure, you could run DOS programs (which you could write yourself), but there was no real integration for custom programs.
(grumble, grumble) and now (after http://www.osnews.com/comments/30775 ) Windows for some reason inside quotation marks… if you want to beat some record at unnecessary quotations ( https://www.reddit.com/r/UnnecessaryQuotes/ & https://www.mirror.co.uk/usvsth3m/11-times-unnecessary-quotation-mar… & https://en.wikipedia.org/wiki/The_%22Blog%22_of_%22Unnec… ) why didn’t you similarly write all instances of “GEOS”?
(and while daydreaming about GEOS, you forget that Windows at least had memory protection…)
Anyways, as for the news, I’d kinda hope more for Commodore 64 GEOS, it has more nostalgia value…
Edited 2018-12-07 00:07 UTC
Didn’t expect to see this. I spent a lot of time working on this codebase back in the day.
My memory is fuzzy after how long it’s been, but it looks like this code release is from at least 2001. New Deal and MyTurn had both been working on GEOS before going out of business in 2001. When they both went under, Breadbox licensed the rights, and I was one of the people that did a little cleanup work on the code to release a Breadbox branded release. It looks like that work is in there.
Past that, I’m not sure what really happened. I don’t think there was a ton of feature work after that. I know there was some work to make the code run in 16 bit protected mode, but I don’t know how far that got or if that code is in here.
What do you suppose is the likelihood of this compiling and running on something like DOSBox? I never got a chance to use GEOS back in the day (Amiga user), but some of the posts here have me intrigued.
It runs fine on DOSBox. Before Frank passed away, Breadbox had been working on some projects that ran it on Android tables via DOSBox.
I wonder if this will be turned into desktop environment for *nix/*bsd?
It’s mostly 16 bit x86 assembly code. The more recent applications are C, but all the core is assembly.
You’d basically have to start from scratch rewriting it all to make it into something usable now.
Maybe you could so something crazy with something like the 16-bit emulator (libv86 or something?) that programs like Wine use.
Vaguely like how some desktop programs use WebKit to run a JS+HTML UI…
It could have a use in things like ATM, POS terminals, etc.
I don’t think so. The trend for those systems seems to be to let them run some web browser, write the POS or ATM interface as a “dynamic web page”, and have background servers (running on the same machine) to handle hardware control. Yes, I know, an over-simplified description.
The logical alternative to bloat is – more bloat! 🙂
There was even a time when such were done often in (shudder) Flash / still plenty of such ~POS systems in use.
Hopefully no one else ever has that idea. The last thing I want is my ATM or POS to be running REAL MODE code, with absolutely no memory protection! Imagine the chaos that all the security holes that would open.
I could, however, see this running on some non-critical embedded systems, like a survey interface machine you see in some stores.